feat: DPE-5656 log rotation new options #597
Conversation
There was a problem hiding this comment.
The log-syncing script once a COS relation is formed that waits to ensure that logs are being synced before changing the logrotation config -> the whole mechanism seems clunky. However, it seems like a sure fire way of ensuring that logs are syncing before the logrotation config is changed
Another option would be to check grep mysql.*log ${POSTIONS_FILE} in the constructor of the charm (along with a no-op if the action is already taken) -> this will be unexpected-error proof with a retry mechanism built in (when the next update-status runs). Thoughts?
Co-authored-by: Sinclert Pérez <[email protected]>
…/mysql-operator into feature/dpe-5656-optional_logs
paulomach
requested review from
sinclert-canonical,
shayancanonical,
taurus-forever and
carlcsaposs-canonical
On point. I've refactored to remove the need of the custom event, and rely on update_status instead, since this can be somewhat lazy |
|
|
||
| self.charm = charm | ||
|
|
||
| self.framework.observe(self.charm.on.update_status, self._update_logs_rotation) |
There was a problem hiding this comment.
minor suggestion: we can just call self._update_logs_rotation() here to have it run for any event that comes in (not just update-status). However, upon update-status is good too!
Issue
DA124 implementation
Solution
Adds:
Fixes #539